• J. Soto: Fixed PMTs' positions to match installation placement
  A change in the cathode position has been noticed on v4 (the base geo used for these changes) with respect to v2 (not sure about v3) so that it is no longer at X=0 but at X=-20 cm. This also changed the CRPs' positions in the geometry. @wenqiang-gu would you be able to identify which geometry has been used for the wirecell setup so it can be identified if this change should be reverted or not?

In the wirecell configuration (dunereco/DUNEWireCell/protodunevd/), it still assumes the cathode centers are located at X=0.

We can update the wirecell configuration if needed. Do we understand the actual position?

@wenqiang-gu thank you for the answer. Can you also confirm the drift lenght in the wirecell config? It was 310 cm up to v2 and then 338.5 from v3 on.

Hi @lpaulucc
About the drift length, this I can confirm. 338.5 cm is what we aimed for in the NP02 cryostat when setting the cathode height.

Thank you, @YoannKermaidic. I suppose this is the drift wirecell used then and there is no need to make a new configuration once I return the cathode to x=0 😌

In the mean time, I give few simulations trials this morning with your new files and let you know.

Regarding the overlaps, TPC positions in v5 are exactly the same as the ones seen in this PR (7e23002#diff-b4aef1aca19588eb15eaaf2b350d8137f45bf57421e94fb9bd70cb924f2eb868) but it is causing overlaps. I think the offsets are dislocated on one side but since I am not the one who introduced it, I will not do anything unless I am instructed to.

@wenqiang-gu thank you for the answer. Can you also confirm the drift lenght in the wirecell config? It was 310 cm up to v2 and then 338.5 from v3 on.

In the wirecell, we set the cathode position and extract wire positions from LArSoft. From the current input file, the wire positions are at +/- 341.5 cm, so it should be consistent with 338.5cm drift length.

/cvmfs/dune.opensciencegrid.org/products/dune/dunereco/v10_03_01d02/wire-cell-cfg/protodunevd-wires-larsoft-v3.json.bz2

I can rewrite the input file for wire positions once the gdml is updated.

@wenqiang-gu I can solve the TPC overlaps by changing the signs in this bit

if($ii%2==0){
  if($jj%2==0){
    $quad=0;
        $pcbOffsetY =  $borderCRP/2; # offset of the active area from CRP envelope
        $pcbOffsetZ = ($borderCRP/2 - $gapCRU/4);
    $myposTPCY = $posY-$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
  }else{
    $quad=1;
        **$pcbOffsetY =  $borderCRP/2;
        $pcbOffsetZ =  -($borderCRP/2 - $gapCRU/4);**
    $myposTPCY = $posY+$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
      }

Should I do that?

@wenqiang-gu I can solve the TPC overlaps by changing the signs in this bit

if($ii%2==0){
  if($jj%2==0){
    $quad=0;
        $pcbOffsetY =  $borderCRP/2; # offset of the active area from CRP envelope
        $pcbOffsetZ = ($borderCRP/2 - $gapCRU/4);
    $myposTPCY = $posY-$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
  }else{
    $quad=1;
        **$pcbOffsetY =  $borderCRP/2;
        $pcbOffsetZ =  -($borderCRP/2 - $gapCRU/4);**
    $myposTPCY = $posY+$CRP_y/4 + $pcbOffsetY;
    $myposTPCZ = $posZ-$CRP_z/4 + $pcbOffsetZ;
      }

Should I do that?

If I understand correctly, here is the layout for 4 quads the coordinate:

For quad 0 & quad 1, somehow we should expect same offset in Z and opposite-sign offset in Y?

@lpaulucc, with the latest commit, I get the following error:

cet::exception caught in art
---- OtherArt BEGIN
  ServiceCreation
  ---- ServiceNotFound BEGIN
    Unable to create ServiceHandle.
    Perhaps the FHiCL configuration does not specify the necessary service?
    The class of the service is noted below...
    ---- OtherArt BEGIN
      ServiceCreation
      ---- groupTPCsIntoSets in CRPWireReadoutGeom BEGIN
        could not interpret the CRP geometry correctly
      ---- groupTPCsIntoSets in CRPWireReadoutGeom END
      cet::exception caught during construction of service type dune::DUNEWireReadout
    ---- OtherArt END
  ---- ServiceNotFound END
  cet::exception caught during construction of service type lariov::SimpleChannelStatusService
---- OtherArt END

@YoannKermaidic perhaps the problem is being caused by the change in the TPC offset. I will undo this change and commit again but it is causing an overlap.

Hi,

I confirm that the reverted version works well (i.e. no errors).
How do we proceed with the overlap? Shall we have a dedicated meeting or somebody thinks this issue can be solved?

Any updates on this discussion? I'd be happy to try to merge when a few reviewers think this PR is ready.

@lpaulucc @YoannKermaidic any updates this week? I can try to merge this Friday morning Chicago time if you can get it approved in time.

Hi @aolivier23, I am checking a possible change needed for the positions of some photon detectors. Let's see if we get this sorted out today. Regarding the overlaps, I am not sure what to do since this was not a change introduced by me and I don't know what impact this can have on the charge sim.

Overlaps can cause random effects and photons disappearing or appearing more than they should. @wenqiang-gu @lhwhitehead and Laura Zambelli any idea how to solve this?

Overlaps can cause random effects and photons disappearing or appearing more than they should. @wenqiang-gu @lhwhitehead and Laura Zambelli any idea how to solve this?

Hi @lpaulucc , perhaps you could revert the changes in PR #123 ? That PR was introduced to align the TPC offset at the bottom and top for calibration purpose. However, if geometry overlaps are a bigger concern, we could discuss reverting it.

By the way , Xin and Nitish presented their Python-based geometry package (GGD) at the last collaboration meeting, and it does not exhibit such overlaps. We could consider transitioning to that package in the future.

One point in addition is that we should put back the CRTs:
my $DP_CRT_switch="off"; -> my $DP_CRT_switch="on";

Thank you for your answer @wenqiang-gu . I will contact Nitish and ask about the overlap. I will keep you posted.
Sure, @YoannKermaidic , I can put the DP CRT back on. Not the HD CRTs too, right?
I get an extra overlap with the DP CRTs switch on
Overlap ov00002: volDetEnclosure/volSteelSupport_Top overlapping volDetEnclosure/volBeamPipe_0 ovlp=121.06

@lpaulucc @YoannKermaidic any updates on this PR? I'm going to hold off from merging it until you post here (or on Slack if you prefer) that it's ready. Thanks.

Thanks, @aolivier23 . I hope next week to have time to identify the changes that were made in the geometry using GGD to correct the TPC overlaps and make a new (and hopefully final) commit.

Any updates @lpaulucc or others? I'll leave this out of the release this week unless I hear back. I'd be happy to give you a few hours to work on this if you think it's almost ready.

Sorry @aolivier23 , lots of things going on this week, I could not push this forward :-(

@lpaulucc Any updates here?

Unfortunately, no. If anyone else involved in this conversation could help me identify what needs to be changed, it would go faster, since next week there is an FDC EB meeting and in the following one, a LBNC meeting. From Xin

I fixed some geometry overlap in the GGD version, which explains why the number of overlaps are smaller than the PERL version.
hese are the files @ https://www.phy.bnl.gov/xqian/talks/ProtoDUNE_geometry/
For example, here is the gdml file without wires: https://www.phy.bnl.gov/xqian/talks/ProtoDUNE_geometry/GeGeDe/protodune_nowires.gdml
The files associated with the original PERL can also be found there.

@YoannKermaidic did you by any chance made tests with this geometry? I just looked at the gdd implementation and the code looks the same, active positions look the same, but the ggd gdml has no TPC overlaps... If the simulation is working for both charge and light, maybe it is better to just go ahead. I am having very little time to handle this at the moment :-(

Currently, the GGD file seems to return an error at execution time:

%MSG-i GeometryCore:  Early 05-May-2025 16:39:30 CEST JobSetup
New detector geometry loaded from
	./protodunevd_v5_ggd.gdml
%MSG
%MSG-s ArtException:  Early 05-May-2025 16:39:30 CEST JobSetup
cet::exception caught in art
---- OtherArt BEGIN
  ServiceCreation
  ---- ServiceNotFound BEGIN
    Unable to create ServiceHandle.
    Perhaps the FHiCL configuration does not specify the necessary service?
    The class of the service is noted below...
    ---- OtherArt BEGIN
      ServiceCreation
      ---- GeometryCore BEGIN
        Cryostat #0 does not exist
      ---- GeometryCore END
      cet::exception caught during construction of service type dune::DUNEWireReadout
    ---- OtherArt END
  ---- ServiceNotFound END
  cet::exception caught during construction of service type lariov::SimpleChannelStatusService
---- OtherArt END
%MSG
Art has completed and will exit with status 1.

So more investigations are required before considering the GGD implementation.

Thank you, Yoann. I asked Wei Shi about it. How were the tests with the perl gased geo with the overlaps?

@lpaulucc I think we can close this PR, isn't it?

I have made one last commit where I remove the v5 gdmls created with the perl script and I update the description of it. I think it might be good to have it clearly somewhere that there is a problem with the perl script so that people don't work on this again unless the problem is fixed. What do you think?